The present invention relates generally to remote application data access and more specifically to accessing data from a document management system across various processing platforms.
In existing systems, problems arise between different software platforms and different applications running on these platforms. In addition to problems associated with the executable instructions, there is also compatibility issues regarding data objects used across multiple platforms. For example, if a general application is used to collect data and a specialized application uses the data, problems can arise in accessing the data. Data access and/or retrieval commands may only be readable by the first software platform, causing problems with the second platform.
As the number of remote applications increase, there is a greater demand for usability of these applications across a centralized system. For example, if a processing system includes applications and other executable clients in different platforms, e.g. JAVA, C++, ABAP, or other languages, these systems cannot communicate without one or more translators. This translation is not only computationally expensive, but also can be problematic with advancements in the different systems.
One approach for overcoming problems associated with varying platform applications is a web services architecture. The web services architecture generally describes functionality allowing for communication across different applications in different platforms through a centralized communication protocol.
Web services associated with a central application for document management is problematic when accessing complex applications, such as found with applications associated with centralized document management.
In a document management system it is often required to transfer content of a document, which might have a size of hundreds of megabytes. One problem currently existing is that web services only provide for the transfer of data in a serialized fashion. This data is serially transmitted across a network. For example, in a pure JAVA environment, streaming is used to transfer large data content. Streaming is not supported by the web service technology. Sending the whole content in one web service call is also not possible because the server or client will run out of memory.
This serial transfer works with small amounts of data. Web services are typically accessed by a web service proxy and the serialization of data transfer is therefore visible to a client application. With the larger data transfer of the document management system, this client-level visibility can create significant inconveniences for APIs on client applications while accommodating the serial data transfer.
Similarly, web services typically do not distinguish between remote data calls and local data calls. Remote data calls require further processing due to call translations and other factors. In some applications, this process is unnecessary, if the client application and web service end-point are running on the same platform. Typically, the decision if the applications runs on the same server, is often not even done by a user interface developer but depends on the usage at customer side.
For example, if a JAVA-based user interface is built on a document management framework, the user interface can run either on the same platform as the management framework, which may be called a local Scenario, or on a remote platform which is called a Remote Scenario. The user interface developer can either always use the web service API, which is costly in terms of performance with the Local Scenario, or has to distinguish between the Remote and Local Scenario and use two different APIs.
Another problem that arises with web service features is the synchronization of the APIs. A web service API executes on top of an existing API, such as the API for the document management system. Therefore, these two API must be synchronized for efficient and effective operation.
Similarly, in existing systems, if the web service API is enhanced by new features, all client proxies need to be updated to fit to the new web service. As it is difficult to maintain updated proxies, a document management system typically has to support multiple versions of the web service. This increases the size of the web service API and has a direct effect on a total cost of ownership for developing the underlying web services.